The SIP conferencing framework (as defined in draft-ieff-sipping-conferencing-framework-05.txt) defines basic procedures, functionalities and architecture how participants may create and join a SIP multimedia conference session, invite other participants to the session, remove participants from the session, become aware of other participants in the session, and so on. The conferencing framework has been then adopted to many SIP based conferencing standards, like 3GPP R6 IMS (3rd Generation Partnership Project Release 6 Internet Protocol (IP) Multimedia Subsystem) conferencing service (as specified e.g. in TS 24.147), OMA-PoC (Open Mobile Alliance—Push-to-talk over Cellular), and OMA-IM (Open Mobile Alliance—Instant Messaging).
The above framework describes how a SDP (Service Description Protocol) offer/answer mechanism specified in the IETF (Internet Engineering Task Force) specification RFC (Request for Comments) 3264 can be used to add, remove and modify media streams and their attributes in the multimedia conferencing session.
In a Multimedia conference session a user should be able to start the session with one particular media (e.g. PoC audio, IM, full-duplex audio, full-duplex video, etc) and add another media later on. The conferencing control function should then communicate the added media to other participants in the conference session, e.g., via an SDP offer in a SIP re-INVITE or a SIP UPDATE request which are described in the IETF RFC 3311. In this way the other participants learn that a new media has been added and they can start to use it in the session.
On the other hand, the same SDP offer/answer mechanism can be used also by a participant to modify the connection portion, i.e., call leg, between this participant and the central control point (e.g., focus in SIP conferencing terminology) of the conference, only. In this kind of session modification of the SIP conferencing framework, the focus should not modify the other participant's media sessions. For example, in the SIP conferencing framework, if one participant wants to put the full duplex audio media on hold, this is done by SDP offer/answer in re-INVITE/200 OK between this participant and the focus, but the focus should not send re-INVITE to other participants, since they are not put on hold and should thus be able to continue communicating as before.
Thus, the central control point needs to be able to determine, what SDP offers should be communicated to other participants and what are kept between a requesting participant and the focus only. In some media modifications, the central control point can determine this based on the SDP offer attributes. For example, if one participant puts the media in a conference session to “on hold”, typically the central control point should not put the other participants to hold, but instead keep the media modification within this particular SIP dialog, i.e. between the participant and the focus. But with some SDP offers the central control point has no means to know whether the media modification should be sent further. For example, if the conferencing session includes audio and video media and some participant wants to remove the video from his/her leg only (e.g. moves to a cell which cannot offer enough bandwidth for video), but the other participants do not have this limitation, i.e., they would like to continue with both audio and video.
The current SDP offer/answer mechanism in SIP conferencing framework is not enough to distinguish whether the media manipulation should be limited to one call leg or communicated to all participants. IETF XCON is solving a similar use case at the moment. There, a framework for media control protocol is defined, which a participant can use to control the media policies of the other participants, e.g. remove video from certain participant, mute one participant (remove the audio sending capability) and so on. However, the XCON work has been very slow, and the result anyhow will be a new protocol between the participant and the focus.
What OMA-IM and OMA-POC would need is a simple SIP based solution for adding and removing media, from standardization time schedule point of view, the IM and POC are not able to wait results from XCON, and they don't need the complex XCON framework and the other more advanced capabilities of the media policy control protocol.